home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-05
/
aprite.zip
/
APRITE.DOC
< prev
next >
Wrap
Text File
|
1991-08-31
|
23KB
|
540 lines
╔═══╗ ╔═══════╗ (WS)
║ ║ ║ ║ ║ ║
╔╝ ╚╗ ║ ║ ║
║ ║ ║ ║ ╠══
╠═════╣ ╔═════╗ ╠══╦════╝ ║ ║ ╔═════╗
╔╝ ╚╗ ║ ║ ║ ╚╗ ║ ║ ║ ║
║ ║ ║ ║ ║ ╚╗ ║ ║ ╠═════╝
║ ║ ║ ║ ║ ╚╗ ║ ║ ║
╠═════╝ ╚═════
║
║
║
*
ApRite / ApRun : Application System
Purpose:
Grant rights to applications: Run applications with NetWare
rights that differ from the rights of the person calling the
application.
The complete system is based on NetWare security.
Features:
- Allow users to change user ID while 3rd party applications
are run.
- Multiple security levels based on NetWare security.
- Management tool to administer and view the internal rights
system.
- Built-in self test for virus infection.
Author:
Wolfgang Schreiber (all rights reserved)
Components:
ApRite.EXE Administration tool
ApRite.DOC Documentation
ApRun.EXE Launch applications
*
License:
This is a fully operable beta version of ApRun/ApRite. It can
be tested on any number of file servers. About 60 days after
its installation on a server it will disable itself.
When the demo time is over, only the options "ApRite /?" and
"ApRite /Destroy" will remain active.
Warning: if the system detects a file server date change it
might disable itself immediately)
The publisher has thoroughly developed and tested the functions
of ApRun/ApRite but cannot take any liability for adverse
effects or damage that might be caused by software
malfunctions, erroneous or incomplete documentation.
The complete product will be published in the 4th quarter of
1991. Its retail price will be US $99 (site license). Orders
can be sent directly to the publisher. International
distributors wanted.
*
Publisher:
Dr. Wolfgang Schreiber
Schanzenstr. 74
4000 Dusseldorf (Germany)
Fax: (1149) - 211 - 55 64 69
Any comments, suggestions, or error reports are welcome, and
will result in a new release of ApRun/ApRite.
Written in Borland's TurboPascal v6.0
*
Syntax:
ApRite [parameters]
ApRun <command>
Accepted parameters:
ApRite /Install
Initiate or re-initiate application system
ApRite /Destroy
Delete/Remove the complete application system
ApRite /Masters [+|- <user>]
List/Define accepted application users
ApRite /SLaves [+|- <user>]
List/Define users that are accepted as slaves
ApRite /Admin [+|- <user>]
List/Define application system administrators
ApRite /Allow command<user>
Allow [user] access to specified command
ApRite /Remove <nr>
Remove application from application system
ApRite /SHow
Show status and list current allowed commands
ApRite /STatus [Pause|Cont]
Show or change application system status
ApRite /?
Display syntax overview
*
Concepts:
ApRite is using a concept called 'Application System' and its
implementation in based on the NetWare concept of a 'Job
Server'.
ApRite uses the terms 'Application System', 'MASTER', 'SLAVE',
'ADMINISTRATOR', 'COMMAND', and 'OPTIONS'. Usage of those terms
must be explained shortly.
Application System: The term 'application system' is used to
describe the complete environment supplied by ApRite and ApRun
to support rights granted to applications.
The application system must be initialized by the Supervisor or
an equivalent before users can access it.
To explain the other concepts we will refer to some command
lines as examples (assumed that U_M and U_S are valid user
names):
1) "ApRite /Allow SYSCON U_M" issued by U_S (Slave)
2) "ApRite /Allow FILER" issued by U_S (Slave)
3) "ApRun SYSCON" issued by U_M (Master)
SLAVE: A slave is a NetWare user who grants his/her NetWare
rights to a master, whenever the master will call a specified
program.
A slave must have been admitted to the application system by
the SUPERVISOR ("ApRite /SLaves ...").
The slave must have specified the commands (and its accepted
masters) that can be run in his/her name, before any master can
run an application in the name of a slave, ("ApRite /Allow
...").
In the example given above the user U_S gives the user U_M the
right to call SYSCON with the rights of user U_S (command 1).
Then U_S allows every legitimate application system master to
run FILER in the name of U_S (command 2).
MASTER: A master is a NetWare user who is logged in to a
NetWare file server and wants to run an application with
different rights than those that he usually has.
Masters must have been admitted to the application system by
the SUPERVISOR ("ApRite /Masters ...").
A master can issue a program call with the rights of a 'slave'
if the slave has allowed (this master) to run an application in
his/her name.
COMMAND/OPTIONS: A standard DOS command line usually contains
the (path and) name of an executable command (with or without
additional options/parameters).
The term 'Command' in this script includes all characters up to
the first blank in the command line. It consists of an optional
valid DOS path followed by a file name and it may include the
extension of the application.
The term 'Options' refers to everything that follows the first
blank in the normal DOS call.
ADMINISTRATOR: An application system administrator can view and
change the status of the application system. The administrator
can see all allowed applications, can remove specific
applications from the system, can halt or restart the system.
By default only the person who installs the application system
is created as system administrator.
New administrators can be defined by the supervisor ("ApRite
/Admin ...").
*
Installation:
- Copy all files from the installation disk to a NetWork
directory;
- Setup the system by calling "ApRite /Install"
- Define legitimate slaves with "ApRite /Slaves ..."
- Define legitimate masters with "ApRite /Masters ..."
- A legitimate slave grants application rights with "ApRite
/Allow ..."
- Legitimate masters now can call "ApRun" to start the
admitted applications.
*
Quick Start:
Within 5 minutes you can get a quick impression of the
capabilities of ApRun:
1) Initiate ApRun:
"ApRite /Install"
2) Give a second user (e.g. GUEST) the right to run SYSCON in
your name:
"ApRite /Allow SYSCON GUEST"
3) Login as GUEST and run SYSCON (with/without ApRun):
"ApRun SYSCON"
If you want to remove GUEST's privileges you have two choices:
4a) Login as Supervisor and revoke the privileges:
"ApRite /Remove <nr>" [Insert appr allowance nr]
4b) Remove GUEST from the list of accepted masters:
"ApRite /Master - GUEST"
*
Security:
The application system includes several layers of protection to
ensure that only accepted users get access to the system:
- only a Supervisor can initiate the system;
- only specified users can get access to the system; they must
have been admitted to the system as 'slaves' or 'masters' by
the supervisor;
- the user ('slave') who gives his rights to other users
('masters') must actively allow those users access to
specified applications;
- only the specified applications can be called; use of these
applications can be restricted to specified persons;
- the master can call the selected applications only if those
applications have not been changed since access was granted;
- the supervisor or an assigned 'administrator' can remove
specified applications from the system;
- the supervisor or administrator can monitor and change the
current status of the application system.
- The automatic self test for virus infection will display a
warning if ApRite.EXE is infected by a virus.
*
Limitations:
Due to NetWare limitations and ApRun's implementation there are
several aspects administrators should keep in mind.
- Number of application configurations: The list of accepted
application/rights configurations may include approximately
200 entries. Customized versions are available on request.
- Memory: since ApRun.EXE has to stay in memory while it
changes the rights of a master to the rights of the slaves,
and since it has to stay active until the original rights
are restored, there is only a restricted area of RAM
available to slave applications.
Generally ApRun.EXE takes about 30 kB of RAM during the
execution of slave applications. The RAM available to
applications will be higher if those are COM or EXE files,
a little less with BAT files (since ApRun uses COMMAND.COM
to run batch jobs).
If memory is a problem, you might consider to use 3rd party
memory manager (like HIMEM, EMM386, or QEMM386) to load some
drivers and TSRs to high memory areas. DOS v4.x will usually
leave less memory to applications than DOS v3.x or v5.x.
- Multitasking: if ApRun is used in a multitasking environ-
ment, ALL tasks will change to the slave's identity as long
as one task runs an application with ApRun. Similar
considerations apply to task switching environments like
DR-DOS v6.x or MS-DOS v5.x.
- TSR programs: The complete station of the master will
receive the rights and identity of the slave during program
execution. Obviously this will affect TSRs that have been
loaded previously, too. Therefore TSRs might in some cases
represent a breach in security since they receive the same
rights as the legitimate application.
- Application Updates / Program changes: If a slave allows
access to an application ApRun tries to ensure that this
program is run without any changes. Future masters can run
the accepted application only in its current form (for
security reasons). Any changes to the program will prevent
masters from being able to start that application. The slave
has to re-allow access whenever an application is modified.
Due to the above mentioned limitations the following
suggestions are strongly recommended:
- Do not run active background applications in multi-tasking
environments. Since those background applications' rights
are also changed, they might create unexpected results.
- Create special users who only have the rights to run one
application. The trustee rights of those users might include
only a single directory. Accept only those user names as
slaves. Take into account that background applications
(e.g. TSRs, Windows applications) receive the slave's
rights, too.
*
Syntax: ApRite [/parameter]
All options of ApRite can be abbreviated as long as those
shortcuts are unique: "ApRite /I" or "ApRite /SH" are valid
shortcuts.
This overview presents optional parameters within square
brackets "[xxx]", user supplied names (e.g. user names or
commands) in angle brackets "<xxx>". Upper vs. lower case
letters do not make any difference.
*
ApRite /?
Display syntax overview
This command give an overview over the features and available
parameters of ApRite.EXE with basic explanations of their effects.
Example: ApRite /?
*
ApRite /Install
Initiate or Re-Initiate application system
Before using any of the following ApRite parameters the
application system has to be established.
The installation procedure will only take about a second and
will initiate security and all relevant variables.
None of the ApRite/ApRun application parts stays resident in a
workstation's RAM. The application system uses similar bindery
security as NetWare itself; it will store all security
information in the NetWare bindery.
WARNING: When "ApRite /Install" is issued a second time, it
will completely reset the application system: all masters,
slaves, administrators, or information about accepted
applications will be removed.
If you unintentionally have run "ApRite /Install" a second
time, you might recover your previous status by restoring a
backup copy of the bindery.
This option is for supervisors only.
Example: ApRite /Inst
*
ApRite /Destroy
Delete/Remove the complete application system
This option can be used to completely remove the application
system structure from your file server.
The only way to recover from the effects of "/Destroy" is to
restore your previous bindery from backup media.
This option is for supervisors only.
Example: ApRite /Dest
*
ApRite /Masters [+|- <user>]
List/Define accepted application users
See the discussion of the master-slave concept above. Masters
are NetWare users that are allowed to take the identity and
rights of a 'slave' while a program is executed. Only the users
admitted to the application system as masters are allowed to
run applications with the temporary ID of a slave.
Before a slave can specify a user as master (that means the
master gets the right to run the application in the slave's
name) the supervisor must have admitted the future master to
the application system. This is done with "ApRite /Masters ..."
Specifying '+' will add new masters, '-' will remove existing
masters.
Only users - no groups - can be accepted as masters.
A slave with supervisor rights can implicitly add masters with
the "/Allow" option (see there). This option is for
supervisors only.
Example: ApRite /Master + guest
ApRite /Master - guest
ApRite /Ma + guest
*
ApRite /SLaves [+|- <user>]
List/Define users that are accepted as slaves
See the discussion of the master-slave concept above. Slaves
are NetWare users whose rights are transferred to a master
while a program is executed.
Only the users admitted to the application system as slaves are
allowed to transfer their rights to a application user
(master).
Before any slave can allow an application to be run in the
slave's name, the supervisor must have admitted the user as
slave to the application system. This is done with "ApRite
/SLaves ..."
Specifying '+' will add new slaves, '-' will remove existing
slaves.
Users and groups can be accepted as slaves.
This option is for supervisors only.
Example: ApRite /Slave + guest
ApRite /Slave - guest
ApRite /SL + everyone
*
ApRite /ADmin [+|- <user>]
List/Define application system administrators
An administrator can monitor the status of the application
system, view the list of accepted slaves, masters, and
applications, and remove specific applications from the system.
The administrator is comparable to a queue operator in the
printing environment.
Specifying '+' will add new administrators, '-' will remove
existing administrators.
Users and groups can be accepted as slaves.
This option is for supervisors only.
Example: ApRite /Admin + guest
*
ApRite /ALlow [command[<user>]]
Allow [user] access to specified command
The option "/Allow" enables a slave to specify, what command is
allowed to be executed in his/her name. This option adds the
new command to the list of accepted commands. An accepted
master is thereby enabled to run this command in the name of
the slave.
The command must contain the filename and may include an
optional drive/path specification and/or extension. ApRite
searches for the specified command file to add it to its list,
so the application must be in the default drive or in one of
the search drives, if no path is specified.
The specified command can be located on a local drive or second
file server, but the rights change will always affect only the
current default server.
If the application (and optional master) are accepted by the
system, it will display the new list of accepted applications.
Each registered application automatically receives a unique
application ID. This ID can be used to remove specific
applications from the system (if desired).
All valid file names will be accepted, but only COM, EXE, and
BAT files give sense.
To use the parameter "/ALLOW" the user needs to be in the list
of accepted slaves, and he/she needs search/file scan rights in
the directory of the specified command.
If "ApRite /ALlow" is not followed by a command, it will list
the current accepted applications entered by the user.
If no user is specified after the command, the application can
be started by any accepted master. If the specified user is
unknown or not accepted as master the command will not execute.
If a supervisor equivalent specifies a user that is no master
yet, the system will automatically add the user to the master
list.
Only users - no groups - can be accepted as masters.
This option is for supervisors and accepted slaves only.
Example: ApRite /Allow syscon
ApRite /Allow syscon.exe guest
ApRite /Al k:\sub\this.bat guest
*
ApRite /Remove <nr>
Remove application from application system
Every entry in the list of accepted applications can be
identified by its entry ID.
Applications can be removed from the system list by a system
administrator or by the slave who added the entry to the list.
This option is for supervisors and administrators only.
Example: ApRite /Remove 473
*
ApRite /STatus [Pause|Continue]
Show or change application system status
Comprehensive system status information is displayed.
In addition to the status display a supervisor or administrator
can change its status. 'Pause' will de-activate the application
system without destroying any of the stored information:
Currently active ApRun applications can be continued, but no
master can start new ApRun commands. 'Continue' will
re-activate the application system.
This option is for supervisors, administrators, and the
initiator slaves only.
Example: ApRite /Status
ApRite /St pause
ApRite /St Con
*
ApRite /SHow
Show status and list current allowed commands
'/SHow' will not only display the short status report, but
additionally list the current accepted slaves, masters,
administrators, and applications. If applications are in use by
masters, their names will be displayed.
This option is for supervisors and administrators only.
Example: ApRite /Show
*
ApRun <command> [parameter list]
Run applications with another identity
If an accepted master wants to start an accepted application in
the name of a slave, the command must be launched by ApRun.
Without ApRun the application would run with the normal rights
of the program caller.
The command can be followed by the parameters as required by
the launched application's syntax. Use the normal command
syntax, and simply add 'ApRun' at the beginning of the command
line.
Masters who want to launch applications need Search/File Scan
rights in the application directory. If the command is not to
be found in one of the master's search drives, it must include
a drive/path specification.
ApRun.EXE will use approximately 30 Kb of the workstation RAM
while the launched application is running. It therefore limits
the RAM available to that application. Since ApRun is not a TSR
program it will not stay in the workstation memory except
during the execution of the launched program.
This option is for accepted masters only.
Example: ApRun fconsole
ApRun NCOPY Z:*.* k: /sub
ApRun C:\this.bat par1 par2